A communications system typically includes two devices which can communicate with each other either directly or via one or more intermediary communications devices of the communications system. Some examples of communications devices include: private branch exchanges, data terminal equipments, central office switches, ISDN customer premises equipment, etc. These devices communicate with one another according to one or more communications protocols or sets of semantic and syntactic rules for communicating. Some examples of communications protocols include: LAPD (Q.921), Q.931, X.25PLP, LAPB, T.70, T.62, DTAM, and V.120.
Illustratively, devices of the communications system contain protocol software for achieving communication according to the different communications protocols. Such protocol software may be hierarchically organized into levels called layers according to the Open Systems Interconnection (OSI) model. According to OSI, communications protocol software for communicating on the highest layer may be used for requesting high level or abstract communications goals. Communications protocol software of each lower layer may be used for requesting more specific sub-goals of higher layers. Finally, communications protocol software of the lowest layer may be used for requesting low level or actual physical tasks (i.e., the actual transmission or reception of data signals). Typically, a communicating device communicates by first generating a request to perform some relatively abstract goal using high layer communications protocol software. This in turn may cause the device to generate one or more requests to perform more specific sub-goals of the abstract goal using lower layer communications protocol software, etc., until one or more requests are generated using communications protocol software of the lowest layer.
U.S. Pat. Nos. 3,869,603, 4,055,801, 4,108,358, 4,713,815, 4,759,019, 4,821,266, 4,916,641, and 5,111,402 disclose automated test systems for testing a variety of types of hardware. Advantageously, implementations of communications protocol software for operating devices of a communications system are tested in a simulated environment before they are deployed in the equipment of the communications system. To that end, the communications protocol software implementation under test (IUT) is tested by emulating the data and control message inputs which may be received from higher and lower layer communications protocol software. If in response to these inputs, the IUT outputs the correct data and control messages (as per the protocol of the higher or lower layer), the IUT passes the test.
Traditionally, IUT's have been tested in a test environment 100 such as depicted in FIG. 1. An upper tester 110 is provided for simulating communications protocol software of a higher layer than an IUT 120 from which the IUT 120 may receive messages, or to which the IUT 120 may transmit messages. For example, the IUT 120 may be an X.25PLP software implementation (layer 3 communications protocol software) and the upper tester may contain a T.70 software implementation (layer 4 communications protocol software). The upper tester 110 transmits to, and receives from, the IUT 120 different kinds of simulated inputted data and control messages according to a higher layer protocol. Likewise, a lower tester 130 is provided for simulating communications protocol software on a lower layer than the IUT 120 to which the IUT 120 may transmit messages, or from which the IUT 120 may receive messages. In the above example, the lower tester 130 may contain a LAPB software implementation (layer 2 communications protocol software). The lower tester 130 transmits different kinds of simulated input data and control messages according to a lower layer protocol.
The simulated input data and control messages of the upper and lower testers may be obtained automatically from a test script file 111 or 131, respectively. Alternatively, the input data and control messages may be inputted by a user in an interactive session. In response to receiving these inputted messages, the IUT may output messages to the upper tester 110 and/or the lower tester 130. As shown by the line 140, the test environment 100 must provide intricate synchronization procedures so that the upper tester 110 and lower tester 130 simulate, as close as possible, the actual environment in which the IUT 120 is to be deployed.
FIG. 2 shows a first conventional communications protocol software test system 200 which provides a test environment according to the general environment 100 (FIG. 1). The test system 200 has a testbed 210 which illustratively may be a computer such as a Micro Vax.TM., manufactured by Digital Equipment Corporation. The IUT 220 is maintained in a separate device 230, e.g., the actual hardware in which the IUT 220 is to be deployed. The testbed 210 communicates with the device 230 via an ISDN S-interface bus 212. Furthermore, a user 240 may input data and control messages to, and receive data and control messages from the device 230. The device 230 in which the IUT 220 resides has lower layer communication protocol software 251 and upper layer communication protocol software 252 which serve to temporarily store information transmitted to the IUT 220 or received from the user 240 or testbed 210.
In operation, the testbed 210 serves as an automatic lower tester. The testbed 210 automatically feeds simulation input data and control message data from a test case file 260 to the IUT 220. The user 240 serves as an upper tester. The user manually inputs data and control messages to, and receives data and control messages from, the IUT 220 during an interactive session. For example, if the testbed 210 is a telephone, the user 240 might lift the handset from the cradle (creating an off-hook signal) and press keys on the telephone keypad. The user receives data from the lower tester 210 in the form of a dial tone, etc.
FIG. 3 depicts a second conventional test system 300 according to the conventional architecture 100 (FIG. 1). An upper tester 350 is provided which is also called the test responder. Both the test responder 350 and the IUT 320 are stored in the device 340 which can be a Sun Microsystems' SUN 3.TM., SUN 4.TM., or SPARC.TM. computers.
The test system 300 has lower tester 330 in the form of a device such as a Sun Microsystems' SUN 3.TM., SUN 4.TM., or SPARC.TM. computers. The lower tester device 330 is a separate device from the device 340. The two devices 330 and 340 can communicate with each other, e.g., via a Sun Microsystems, SUNLINK OSI.TM. interface 355.
The lower tester 330 contains a test driver program 310, a referencer 360 and an exception handler 370. The referencer 360 is a certified communications protocol software implementation of the same communications protocol(s) as the IUT 320. The referencer 360 may thus be used as a reference as to how the IUT 320 should respond.
The exception handler 370 operates under the control of the test driver program 310. The exception handler 370 is provided for purposes of altering the messages communicated between the referencer 360 and the SUNLINK OSI.TM. interface 355. The exception handler 370 can thus create an abnormality in the messages outputted from the referencer 360.
In operation, the user compiles a test case file which includes the data to be inputted to, and outputted from, the upper tester 350 and the lower tester 330. The test driver 310 then transfers instructions, using Test Driver Responder Protocol (TDRP) language, regarding the operation of the upper tester 350 to the test responder 350 via the referencer 360, SUNLINK OSI.TM. interface 355 and the IUT 320. The device 340 and the device 330 then execute appropriate steps to automatically feed input messages to the IUT 320 and to receive output messages therefrom.
The prior art test systems 200 (FIG. 2) and 300 (FIG. 3) have several disadvantages. In the test system 200, the user is required to enter appropriate input data in an interactive session. Such an interactive session is tedious and prone to errors. Moreover, because of the limited speed of human data entry, the test requires a long time to complete. The time factor is important when considering that the same test may be applied to several different IUT's or reapplied to the same IUT in the course of developing the IUT.
In using the test system 300, the IUT is compiled together with a test script file which contains the inputted messages of the upper and lower tester. The tests carried out by each test script file may be planned and separately stored ahead of time. These test script files may then be compiled with the IUT to produce an executable object (machine language) file. However, any time a test or the IUT is modified, the files must be recompiled. Furthermore, an object file (containing the executable machine language code) is produced each time the IUT is compiled with a test script file. Thus, a great deal of effort must be expended in managing the files, for example, to ensure that only current object files are stored and only unneeded object files are discarded.
In both test systems 200 and 300, the data outputted from the IUT is transmitted through the upper and lower testers. The upper and lower testers may have certain error contention capabilities in which the upper and lower testers continue to perform normal operations even in the event erroneous data and control messages are outputted from the IUT. Thus, the upper and lower testers may filter out erroneous data and control messages outputted from the IUT. This reduces the ability to fully test the IUT.
It is thus an object of the present invention to overcome the disadvantages of the prior art.